Transmission Control Protocol/Internet Protocol (TCP/IP) based Ethernet technology, after more than 30-year development, has become a dominant local area network (LAN) technology so far. It has managed to enter the core network of the public network, root in the metropolitan area network, and is gradually penetrating into the public access network. For almost every application, Ethernet technology has actually become a standard for transmission protocol. Having the virtue of simplicity, flexibility, and low cost, the Ethernet technology far exceeds some traditional technologies, such as Token Ring, Fiber Distributed Data Interface (FDDI), and Asynchronous Transfer Mode (ATM).
With the development of Ethernet based LAN and Ethernet switching technology, virtual local area network (VLAN) technology pops up. VLAN, defined by Institute of Electronic Electrical Engineering (IEEE), is a technology for LAN partition established based on LAN switch.
Meanwhile, it is desirable for the IP network to not only provide the traditional e-mail service, internet-surfing service, etc., but also provide point-to-point forward control service, etc. Multi-Protocol Label Switching (MPLS), developed based on IP technology, is a technology that incorporates the ATM technology and a technology that is based on a label between the link layer header and network layer header for accelerating the forward operation. MPLS is capable of combining various network technologies and link layer technologies. It allows extensive applications in the fields of Virtual Private Networking (VPN), Traffic Engineering (TE), Quality of Service (QoS), etc., at present.
The building block for MPLS network is a downstream label switch router (LSR). The network, constituted by LSRs, is called MPLS domain. The LSR which is located along the edge of MPLS domain and couples to other user network is called edge LSR. The LSR which locates inside the MPLS domain is called core LSR. The core LSR may be a router supporting for MPLS, or an ATM-LSR upgraded from the ATM switch, and the like. The labeled packet is transmitted along a label switched path (LSP) comprised of a series of LSRs. The LSR at entry is called “Ingress,” while the LSR at exit is called “Egress.” For instance, a path connected by LSR device 2, 3, 4, and 5 is a LSP. The entry to the LSP is LSR device 2. The exit to the LSP is LSR device 5.
MPLS is vital to the realization of Traffic Engineering. It may accomplish various traffic engineering functions accomplished by other models. Moreover, it is cost effective, and more importantly, it may automate part of the traffic engineering functions. Currently, MPLS TE is implemented with the support of Resource Reservation Protocol (RSVP)-TE. It extends the TE based on RSVP. In RSVP-TE, there are two main messages, PATH and RESV. Both of them are the extension of corresponding messages in the RSVP. RSVP-TE provides MPLS TE with a configurable display path and a LSP whose bandwidth can be reserved. Moreover, the RSVP-TE supports swift re-routing, preemption, and loop detection for LSP.
In the existing RSVP network, RSVP node utilizes a RSVP HELLO mechanism to check the reachability of a neighboring node. Such mechanism provides a point-to-point error check. If the RSVP node detects that its neighboring node has been lost, it handles such situation according to the practice conducted when the link layer communication fails. Such mechanism is generally used in the scenario where link check is not available or not on time.
Specifically, RSVP HELLO mechanism includes two types of messages, “HELLO REQUEST” and “HELLO ACK.” Any RSVP node which enables the RSVP HELLO mechanism will send a “HELLO REQUEST” message at regular interval, which is set by configuration or by default. The node receiving the HELLO REQUEST message replies a HELLO ACK message in return. Both two types of messages include two fields “Src_Instance” and “Dst_Instance.” Node check is accomplished by collecting/storing the instance value of the neighboring node.
RSVP Node A fills the Src_Instance field of the HELLO REQUEST message with a value which represents the node itself and corresponds to a neighboring node when transmitting the HELLO REQUEST message. For instance, suppose Node A has two neighboring Nodes B and C. Node A fills Src_Instance field with A1 in the HELLO REQUEST message transmitted to B, and fills Src_Instance field with A2 in the HELLO REQUEST message transmitted to C. The filled value remains unchanged when exchanging the HELLO message with its corresponding neighboring node. In addition, the value of Src_Instance field in the latest HELLO message received from the corresponding neighboring node is used to fill in the Dst_Instance field in the REQUEST message. If Node A has never received the HELLO message from the neighboring node or the neighboring node is deemed as lost, the value of Src_Instance field is stored locally as zero.
After receiving the HELLO REQUEST message from Node A, RSVP Node B compares the value of Src_Instance field in the message with the locally stored value of Src_Instance field which is received most recently. If Node B has never received the HELLO message from Node A; that is, the locally stored value of the Src_Instance field concerning the neighboring node (Node A) is zero, then the locally stored value of the Src_Instance field concerning the corresponding neighboring node is updated. If two Src_Instance field values are different, or the Src_Instance field value in the current received message is zero, then neighboring Node A transmitting the message is deemed as lost. If two Src_Instance field value are identical, Node B returns a corresponding HELLO ACK message.
RSVP Node B receives the HELLO REQUEST message from neighboring Node A and compares the Dst_Instance in the received message with the Src_Instance sent recently. If they are different, it is determined that an error occurred upon the neighboring Node A. If the neighboring Node A continuously sends REQUEST message containing incorrect and non-zero Dst_Instance value, the neighboring node A is deemed as lost.
After Node B determines that two Src_Instance field values are identical and returns a HELLO ACK message, the corresponding neighboring Node A receives the returned the HELLO ACK message and compares the Src_Instance field value in the message with the Src_Instance field value received from B most recently. If different, the neighboring Node B is deemed as lost. Then, Node A compares the Dst_Instance field value with the Src_Instance field value transmitted to neighboring Node B most recently. If different, the neighboring Node B is also deemed as lost.
If the SVP node has neither received the HELLO REQUEST message from neighboring node nor received the HELLO ACK message from the neighboring node for several consecutive periods (configurable), the neighboring node is also deemed as lost.
If the RSVP node detects that its neighboring node is lost, the neighboring node is handled according to the practice conducted when the link layer communication fails.
In practice, according to the foregoing approach, the neighboring node may not be able to make correct determination on whether or not the RSVP node is lost under the circumstance when the RSVP node disables the RSVP HELLO mechanism.
The reason for that is the neighboring RSVP node, according to in the prior art, utilizes the RSVP HELLO mechanism to check the availability of its counterpart. After transmitting the HELLO REQUEST message to the neighboring RSVP node, a determination is made on whether or not the neighboring node is lost, according to the HELLO ACK feedback message from the neighboring node. However, such method of determination may get a correct result only when all of the RSVP nodes enable the RSVP HELLO mechanism. Once any one of the nodes disables the RSVP HELLO mechanism, this node would not return the HELLO ACK message after receiving the HELLO REQUEST message from its neighboring node. However, this node is not lost in fact. In this case, because its neighboring could not receive the HELLO ACK message, the neighboring node may not be able to make determination on whether the RSVP node is lost or not, or may get an incorrect result of the determination. For instance, RSVP node is likely to make the determination that the neighboring node is lost when the RSVP node has not received the HELLO ACK message from some neighboring node for several consecutive periods. The network side then handles the neighboring node according to the practice conducted when the link layer communication fails, mistakenly removes the LSP passing through the neighboring node, and, thus, results in the interruption in the LSP.